Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

lt-body: add enableScaffolding option #421

Merged
merged 2 commits into from
Jun 27, 2017

Conversation

buschtoens
Copy link
Collaborator

@buschtoens buschtoens commented Jun 8, 2017

This PR adds a scaffolding row (just like with {{lt-head}}) to the {{lt-body}} component.

This way it is possible to have a first row with colspans.

The scaffolding row can optionally be enabled like so:

{{t.body enableScaffolding=true}}

Also removes the now unnecessary style attribute binding from cells/base, which in theory should yield a small performance boost. 🚀

@buschtoens
Copy link
Collaborator Author

Tests failing... I'll look into that.

@buschtoens
Copy link
Collaborator Author

The tests for {{lt-body}} are now aware of .lt-scaffolding-row and ignore these.

@buschtoens buschtoens changed the title lt-body: add scaffoling row by default lt-body: add scaffolding row by default Jun 8, 2017
classNameBindings: ['align', 'isSorted', 'column.cellClassNames'],

isSorted: computed.readOnly('column.sorted'),

style: computed('column.width', function() {
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Are we concerned that this no longer happens when enableScaffolding is set to false?

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I would argue no. Currently, these style attributes don't really have an effect anyway, as the table-layout: fixed makes all but the first row ignore custom widths.

As long as the user doesn't overwrite the table-layout: fixed rule, nothing should change.

The only case where this could matter is, when the user actively decides to change the display from table to something like flex.

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I can undo this, or make it depend on whether enableScaffolding is true or false.

* @type {Boolean}
* @default true
*/
enableScaffolding: true,
Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Maybe it would be more sensible to make this a CP that's the inverse of overwrite.

As we're prepending a scaffolding row, this could lead to some unexpected behavior for people that use selectors like :first-child.

@buschtoens
Copy link
Collaborator Author

@offirgolan Would you like to chime in on the issues raised above? I'd like move this PR forward. :)

@offirgolan
Copy link
Collaborator

@buschtoens this is a risky change as it could introduce many unanticipated issues.

Can you give me an example as to how you would create a table with the first row having colspans? Maybe we can tackle this in a different way.

@buschtoens
Copy link
Collaborator Author

buschtoens commented Jun 16, 2017

I needed to implement headings for table sub sections; basically a slimmed down version of the headings in #434 (sticky rows).

I tested my branch in our project and couldn't find any problems, but i can understand the hesitation and kinda feel the same. Maybe we could inverse the enableScaffolding so users explicitly have to opt-in? Just like with enableSync.

Alternatively, I'm sure I'll be able to come up with some position: absolute magic to achieve faux colspan.

@buschtoens
Copy link
Collaborator Author

I made enableScaffolding default to false and re-added the style binding on BaseCell. This way, if users don't explicitly opt-in, nothing changes at all. I also fixed #404 while I was at it.

When enableScaffolding=true the style CP short circuits and always returns null. This way we save some unnecessary DOM updates.

@@ -33,7 +33,7 @@ test('row selection - enable or disable', function(assert) {

this.render(hbs `{{lt-body table=table sharedOptions=sharedOptions canSelect=canSelect}}`);

let row = this.$('tr:first');
let row = this.$('tr:not(.lt-scaffolding-row):first');
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

out of curiousity did you need to update these tests? enableScaffolding isn't set

Copy link
Collaborator Author

@buschtoens buschtoens Jun 22, 2017

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

In the original state of this PR with enableScaffolding defaulting to true, this was necessary. It isn't anymore, but I precautiously still included this commit. This way the tests will continue to work, even if we might decide to set enableScaffolding by default in the future, or when we copy and paste these cases to write some new enableScaffolding specific tests.

If you feel that this makes the tests harder to comprehend / maintain, I have absolutely no objections to cancel out this commit. 🙂

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Got it. That makes sense.

It's a little confusing since it isn't set.

As an aside there aren't any actual tests that verify enableScaffoliding puts a scaffolding row in the DOM 😲 🚨 🙄

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

That is... correct. 😨

I could swear, that I've written these. 🤔
Gonna push the tomorrow from the office. ☺️

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@buschtoens I dont think this is needed since you have specific tests for when it is enabled. I prefer it like that since it is more contained. If we enabled it by default in the future, we can just turn it off for these test cases.

@buschtoens
Copy link
Collaborator Author

buschtoens commented Jun 23, 2017

I added a test case asserting, that:

  • the first row of the <tbody> is a scaffolding row
  • the second row of the <tbody> is not a scaffolding row
  • the second row of the <tbody> has no style attribute
  • the first actual data row has the correct widths

scaffoldingRow.hasClass('lt-scaffolding-row'),
'the first row of the <tbody> is a scaffolding row'
);
assert.ok(
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

assert.notOk

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Actually I was gonna use that, but I wanted to stay in line with the other tests in this file, which all use

assert.ok(!condition);

Should I leave it or still change to notOk?

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

lol I didn't even realize.
leave it for now... I'll do a PR to migrate to using ember-native-dom-helpers in the tests and I'll fix it up there

@buschtoens buschtoens changed the title lt-body: add scaffolding row by default lt-body: add enableScaffolding option Jun 23, 2017
@buschtoens
Copy link
Collaborator Author

buschtoens commented Jun 25, 2017

@offirgolan Any objections? enableScaffolding now defaults to false, so users have to opt-in explicitly. There also are sufficient test cases asserting, that the actual data rows have the specified widths.

Unless you don't want this feature in ELT, I'll merge. 😉

let column = this.get('column');
if (!column) {
return null;
}
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

let column = this.get('column');

if (this.get('enableScaffolding') || !column) {
  return '';
}

@@ -33,7 +33,7 @@ test('row selection - enable or disable', function(assert) {

this.render(hbs `{{lt-body table=table sharedOptions=sharedOptions canSelect=canSelect}}`);

let row = this.$('tr:first');
let row = this.$('tr:not(.lt-scaffolding-row):first');
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@buschtoens I dont think this is needed since you have specific tests for when it is enabled. I prefer it like that since it is more contained. If we enabled it by default in the future, we can just turn it off for these test cases.

Also removes the style attribute binding from cells/base, if enabled.

Also fixes adopted-ember-addons#404.
@buschtoens
Copy link
Collaborator Author

Thanks for reviewing guys. I made the requested changes. Tests are passing as well. :shipit:

@buschtoens buschtoens merged commit f6f2334 into adopted-ember-addons:master Jun 27, 2017
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants